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1.  Introduction 

The  US.  Army  Harry  Diamond  Laboratories  (HDL)  has  initiated  an  effort  to 
develop  a  suite  of  mobile  test,  measurement,  and  diagnostic  equipment 
(TMDE)  for  monitoring  the  life<yde  nuclear  survivability  (LCNS)  of  mili¬ 
tary  systems.  It  is  desirable  to  monitor  these  systems  in  the  field  instead  of 
returning  them  to  a  depot;  hence,  a  mobile  LCNS  TMDE  suite  is  required. 
There  is  also  a  goal  to  standardize  LCNS  test  procedures  and  logistics. 

Total  program  efforts  consist  of  the  development  and  demonstration  of  a 
complete  mobile  TMDE  suite.  This  includes  all  instrumentation,  operating 
system  hardware  and  software,  and  database  functions  necessary  to  collect 
and  process  LCNS  data.  The  platform  for  the  LCNS  TMDE  suite  (identified 
through  feasibility  studies)  is  an  S280  shelter,  which  puts  several  restrictions 
on  the  configuration  of  the  suite  because  of  its  physical  size.  In  consideration 
of  these  restrictions,  we  chose  an  operating  system  based  on  a  personal 
computer  (PC)  to  control  the  TMDE  suite.  Efforts  to  date  have  concentrated 
on  the  design  and  demonstration  of  the  PC  operating  system/ software  and 
the  ability  to  collect  and  manage  LCNS  data. 


2.  Modules 


Without  prior  knowledge  of  the  hardware  to  be  controlled,  we  are  posed 
with  several  obstacles  in  designing  the  actual  operating  system  software.  We 
thus  developed  and  pursued  the  concept  of  a  modular  operating  system  as 
a  viable  solution  to  many  of  the  problems  that  had  been  identified. 

Characterizing  this  modular  concept  is  a  generic  control  shell,  which  is  the 
foundation  of  the  operating  software,  that  loads  specific  information  from 
external  modules  (see  fig.  1  for  a  graphic  representation  of  shell /module 
interaction).  The  entire  software  package  can  be  developed  without  regard 
to  the  specific  instrumentation  or  hardware,  including  the  PC  itself,  that  will 
ultimately  make  up  the  TMDE  suite.  Adding  any  given  piece  of  hardware  to 
the  TMDE  suite  requires  only  the  creation  of  a  driver  module;  the  entire 
software  package  need  not  be  rewritten. 

The  inherent  flexibility  of  this  modular  design  allows  for  the  addition  of  any 
instrumentation  and  hardware  (current  or  future  technologies).  Similarly, 
changes  to  military  standards  (MIL-STDs)  or  system  requirements  can  be 
incorporated  into  the  software  through  modifications  at  the  module  level. 
The  modular  design  is  so  flexible,  in  fact,  that  the  system  may  be  used  for  all 
types  of  testing  in  addition  to  LCNS  testing. 

2.1  Installation  Module 

The  installation  module  is  comprehensive  in  that  it  provides  configuration 
management  of  the  control  software  and  the  PC  hardware.  The  installation 
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Figure  1.  Modules/ 
program  shell 
interaction. 


software  is  very  similar  to  that  found  in  commercial  software  packages  and 
provides  for  printer/plotter  support,  directory/path  creation,  central  pro¬ 
cessing  unit  (CPU)  speed  determination  (for  aesthetic  purposes),  and  auto¬ 
matic  detection  of  graphics /monitor  capability. 

2.2  Facility  Module 

Closely  related  to  the  installation  module,  the  facility  module  provides 
configuration  management  of  test  instruments  and  data  acquisition  hard¬ 
ware.  The  facility  module  is  very  specific  for  each  particular  TMDE  suite,  and 
contains  information  on  the  suite's  data  links,  sources,  calibration  files, 
sensors  and  probes,  and  any  other  test  hardware. 

From  the  facility  module,  you  may  select  or  configure  complete  end-to-end 
data  links,  check  or  perform  calibrations,  and  substitute  or  add  equipment 
(you  must  also  supply  a  driver  for  each  new  instrument  that  is  to  be 
computer  controlled*).  Specific  data  links  or  hardware  configurations  may 
be  configured,  named,  stored,  calibrated,  and  later  called  up  to  provide 
immediate  setup  configurations  or  provide  instrumentation  histories  to  aid 
back-tracking /troubleshooting  of  previously  measured  data. 


* 


*The  instrument  drivers,  as  well  as  the  calibration  files,  are  actually  contained  within  the  data  acquisition  modules  (see 
sect.  2.6). 
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2.3  Graphics  Module 

The  graphics  module  consists  of  a  series  of  routines  that  allows  you  to 
produce  graphic  representations  of  the  system  under  test,  including  an 
overlay  of  test-point  locations.  The  graphics  module  can  also  plot  and  print 
data  waveforms,  as  well  as  display  existing  graphics  that  may  be  provided 
by  the  test  requirements  module  (see  sect.  2.5).  This  visual  aid  greatly 
enhances  test-point  identification  and  provides  real-time  progress  reports 
by  displaying  completed/uncompleted  test  points. 

2.4  System  Module 

The  system  module  is  a  highly  interactive  collection  of  system-specific 
descriptions  and  LCNS  requirements  for  the  particular  system  under  test.  It 
interacts  with  the  data  acquisition,  test  requirements,  and  graphics  modules 
at  test  time.  The  information  within  this  module  contains  the  parameters  that 
globally  define  the  type  and  amount  of  testing  to  be  conducted  on  the  system. 
The  module  contains  information  for  the  following:  MIL-STD  and  other  test 
requirements,  specific  test  points,  special  test  procedures,  expected  data 
levels  or  baseline  data,  references  to  supporting  manuals  or  graphic  dis¬ 
plays,  and  any  special  logistics. 

2.5  Test  Requirements  (MIL-STD)  Module 

The  test  requirements  module  (a  test-interactive  module)  identifies  and 
defines  the  specific  test  to  be  performed.  The  actual  data  acquisition  and 
instrument  control  modules*  simply  acquire  generic  data,  but  the  test 
requirements  module  specifically  defines  and  sets  the  parameters  for  each 
piece  of  data  to  be  collected. 

The  test  requirements  module  is  actually  a  collective  group  of  submodules. 
In  many  cases,  particularly  for  LCNS  testing,  the  test  requirements  are 
specified  by  a  MIL-STD;  therefore,  the  module  contains  "canned"  MIL-STD 
submodules.  Aside  from  MIL-STDs,  the  module  contains  several  predefined 
"vanilla"  submodules  that  define  certain  common  or  generic  test  types  (e.g., 
shielding  effectiveness,  cable-fault  location,  insertion  loss,  etc).  Further¬ 
more,  there  is  a  vanilla  submodule  that  is,  more  specifically,  a  "dummy" 
submodule.  You  may  input  to  the  dummy  submodule  any  requirements  you 
desire,  therefore  providing  totally  generic  data  acquisition  for  research  and 
development  or  diagnostic  testing. 

2.6  Data  Acquisition  Modules 

The  data  acquisition  module  is  the  heart  of  the  run-time  testing  operation. 
Although  it  will  access  other  modules  for  various  information,  the  data 
acquisition  module  completely  controls  testing  at  the  test-point  level.  All 
instrument  drivers  and  calibration  files  are  contained  or  accessed  from 


*See  section  2.6,  Data  Acquisition  Modules. 
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within  this  module.  If  you  attempt  to  use  any  device  that  either  has  not  been 
calibrated  or  is  out  of  calibration,  the  data  acquisition  module  will  wam  you 
and  suggest  alternative  instruments  or  allow  real-time  calibration  of  the 
instrument. 

Based  on  the  current  test-point  requirements,  the  data  acquisition  module 
will  initialize  itself  into  either  a  frequency  domain  testing  mode  or  a  time 
domain  testing  mode.  Although  the  modes  of  operation  are  functionally 
very  similar,  having  two  different  modes  allows  the  module  to  initialize 
itself  to  inherently  different  test  types  and  increase  the  efficiency  of  the  data 
acquisition  process. 

2.6.1  Frequency  Domain  Testing 

In  the  frequency  domain  mode  of  operation,  the  data  acquisition  module 
uses  one  or  more  network  analyzers  and  spectrum  analyzers*  to  measure  the 
frequency  response  of  one  or  more  test  points  at  a  series  of  discrete  frequen¬ 
cies.  The  module  also  controls  any  auxiliary  equipment  (such  as  amplifiers, 
fiber-optic  links,  probes,  and  sensors)  in  harmony  with  the  analyzers  and  the 
data  acquisition  process. 

Network  analyzers  provide  their  own  source  to  "drive"  the  test  point,  and 
since  the  network  analyzer  can  measure  signals  relative  to  a  reference  signal 
input,  transfer  functions  may  be  measured.  Spectrum  analyzers  may  be 
mated  with  a  tracking  generator,  in  which  case  they  essentially  have  their 
own  source;  or  an  external  source  can  be  selected  and  controlled.  Although 
spectrum  analyzers  cannot  reference  the  input  in  real  time,  references  can  be 
made  with  additional  test  shots.  In  any  case,  all  instrumentation  functions 
identically  as  far  as  the  module  is  concerned;  only  the  device  drivers  differ. 

Once  the  raw  data  have  been  obtained,  the  module  accesses  the  test  require¬ 
ments  and  system  modules  to  obtain  the  data  processing  requirements  and  the 
baseline  data  or  pass-fail  specifications.  The  raw  data  are  first  processed  and  then 
compared  to  the  baseline  or  pass/ fail  criteria.  The  baseline  data  and  pass/ fail 
criteria  are  comparison  points  for  determining  the  integrity  of  the  system  for 
each  test  point.  Baseline  data  may  be  either  the  original  data  collected  during  the 
verification/acceptance  testing  or  the  previously  measured  LCNS  data.  The 
pass/fail  criteria  form  some  parametric  bound  that  defines  the  minimum 
specification  a  system  must  meet  (such  as  a  MIL-STD  shielding  effectiveness 
requirement).  If  serious  discrepancies  exist,  the  module  may  suggest  several 
sanity  checks  (the  integrity  of  calibration  files,  connectors,  cables,  etc)  to  ensure 
that  valid  data  have  been  obtained. 


*Other  devices  can  also  provide  frequency  domain  measurements.  Our  discussion  has  been  limited  to  those  devices  that 
are  computer  controlled  and  the  most  commonly  used. 
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2.6.2  Time  Domain  Testing 

The  function  of  the  time  domain  mode  is  almost  identical  to  the  frequency 
domain  mode  except  that  in  the  time  domain  mode  the  module  uses 
digitizers  or  oscilloscopes  to  measure  the  system  response  at  one  or  more  test 
points.  In  the  time  domain  mode,  the  module  expects  an  external  source,  use 
of  timing/trigger  devices,  and  a  high  degree  of  data  processing.  The  digitiz¬ 
ers  measure  the  instantaneous  response  at  successive  time  increments,  thus 
recording  a  discrete  (digital)  time  domain  waveform.  The  data  may  then  be 
processed  and  compared  to  previous  measurements,  as  was  the  case  for  the 
frequency  domain  mode. 

2.7  Math  Module 

The  math  module  is  simply  a  collection  of  canned  data  processing  routines. 
These  routines  are  accessed  by  the  data  acquisition  module  for  processing 
raw  data.  The  data  acquisition  module  can  access  mathematical  operations 
necessary  to  "scale  out"  instrumentation  effects  or  data  processing  functions 
that  may  be  specified  by  the  test  requirements  and/or  system  modules. 

3.  Run-Time  Operation 

We  will  now  describe  the  modules  and  their  interaction  in  a  real-time  data 
acquisition  operation.  It  is  assumed  that  the  PC  and  the  LCNS  software  have 
been  installed,  and  it  is  also  assumed  that  the  suite's  data  acquisition 
hardware  has  been  configured  in  the  facility  module.  The  description  traces 
an  example  of  collecting  a  single  piece  of  data.  It  should  be  noted,  however, 
that  several  channels  of  data  can  be  acquired  simultaneously. 

The  initial  step  in  performing  LCNS  testing  on  a  system  is  to  load  the  system 
module  from  floppy  disk(s),  provided  by  the  system's  program  manager 
(PM)  or  other  responsible  party  as  defined  by  the  PM.  In  addition  to  the 
system  module,  the  floppy  disk(s)  must  contain  any  historic  or  baseline  data, 
any  special  test  requirements  modules,  and  any  graphics  that  have  been 
produced  by  the  PM.  The  floppy  disk(s)  should  contain  a  text  file, 
"diskfile.dat",  that  lists  all  files  contained  on  the  disk(s). 

The  LCNS  main  menu  has  three  selections  as  indicated  in  figure  2.  The  data¬ 
base  operations  (option  2)  were  not  addressed  in  this  effort  and  will  not  be 
discussed  further.  Option  3,  "Run  Install,"  allows  you  to  selectively  install  or 
change  the  PC  hardware  (monitors,  graphics  card,  printers,  and  plotters) 
and/or  modify  directories  and  paths.  To  load  a  new  test  system,  you  should 
select  option  1,  "Test  Operations." 
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Figure  2.  LCNS  main 
menu. 


Figure  3.  LCNS  test 
operations  main 
menu. 


After  you  select  option  1,  the  test  operations  main  menu  appears  on  the 
screen  (fig.  3).  To  load  a  system  that  has  not  been  tested  by  the  particular 
TMDE  suite  being  used,  you  select  option  3  and  the  'Test  -  Load  'New'" 
menu  appears.  The  'Test  -  Load  'New"'  menu  prompts  you  for  information 
needed  to  create  various  subdirectories  for  data  /file  storage,  and  to  copy  the 
files  from  the  floppy  disk(s)  provided  by  the  PM  (see  example  in  fig.  4). 


LCNS  MAIN  MENU 


1.  Test  Operations 

2.  Data  Base  Operations 

3.  RUN  Install 


Enter  number  of  selection  ?  'ESC'  to  QUIT 


LCNS  TEST  OPERATIONS  MAIN  MENU 

1.  Start  Testing 

2.  Develop/Modify  Test  Plan 

3.  Load  'NEW'  Test  System 

4 .  Facility  Configurations 

5 .  Report  Test  Status 


Enter  number  of  selection  ?  'ESC'  to  leave 
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Figure  4.  Example  of  TEST  -  Load  'New' 

LCNS  test— load  'New' 

screen.  - 

List  of  files  in  "diskfile.dat";  Tank  . sys 

Datal  .bas 
Data2  .bas 
Testl  .req 
SideView.pic 
TopView  .pic 


Enter  Directory  and  Path  for  system 

hit  RETURN  for  c:\lcns\data\  TANK  ->  <return> 

Enter  System  Module  filename 

(hit  RETURN  for  'Tank. sys')  ->  <return> 


(cont ' d) 


Once  the  system  files  have  been  loaded  from  floppy  disk,  you  should  select 
option  2,  "Develop/ Modify  Test  Plan,"  from  the  test  operations  main  menu. 
For  the  most  part,  the  test  plan  is  already  defined  by  the  system  module; 
however,  you  have  the  ability  to  choose  the  order  in  which  test  points  are  to 
be  completed.  A  list  of  all  test  requirements  for  the  system  is  displayed  and 
you  choose  which  tests  are  to  be  performed  first — time  domain  or  frequency 
domain  (fig.  5).  If  you  choose  to  perform  time  domain  testing  first,  the 
frequency  domain  test  requirements  are  dropped  from  the  PC  display,  and 
you  then  choose  the  order  in  which  time  domain  test  types  are  performed. 

The  test  types  listed  are  categorized  by  their  hardware  requirements  rather 
than  by  MIL-STD  or  test  requirements  (e.g.,  current  injection  and  free-field 
illumination).  This  categorization  is  preferred  because  any  given  MIL-STD 
module  may  contain  requirements  for  several  different  test  types,  including 
frequency  domain  and  time  domain  components.  The  test  planning  routine 
forces  you  to  construct  the  most  efficient  ordering  of  the  test  plan  possible, 
by  minimizing  the  number  of  configurational  changes  and,  therefore,  mini¬ 
mizing  down-time.  When  conducting  the  test,  however,  you  always  have 
the  ability  to  dynamically  change  the  test  plan  ordering. 
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Figure  5.  Example  of 
LCNS  test — test  plan 
screen. 


TEST  -  Test  Plan 


Test  requirements  for  "TANK" 

(T) ime  Domain  (F)requency  Domain 


1. 

Current 

Injection 

10 

1. 

Shield  Eff. 

5 

2. 

Free-field  Ill. 

21 

2. 

CW  Ill. 

16 

3. 

Mil-Std 

•XYZ’ 

6 

3. 

Mil-Std  1 ZYX 1 

1  4 

4  . 

Mil-Std 

’PDQ’ 

18 

Select  ' T'  or  'F'  for  test  domain  to  complete  first 
'ESC'  to  leave 


Following  the  ordering  of  test  types,  you  choose  the  order  in  which  indi¬ 
vidual  test  points  will  be  completed  within  each  test  type.  You  then  complete 
this  selection  series  for  the  other  test  domain  (the  frequency  domain  in  this 
example).  The  basic  test  plan  is  then  complete,  and  you  are  returned  to  the 
'Test  Operations"  main  menu. 

At  this  point,  you  may  choose  to  select  option  4  "Facility  Configurations,"  to 
determine  whether  the  stored  data  link  configurations  are  adequate  to 
accommodate  the  testing.  This  examination  is  automatically  conducted,  to 
some  extent,  by  the  software.  The  software  compares  the  descriptions  of  each 
data  link  configuration  in  the  facility  module  to  the  descriptions  of  the 
system's  test  requirements,  and  warns  of  any  deficiencies.  You  may  config¬ 
ure  and  store  the  new  data  link  configurations  at  this  time  or  wait  until  the 
data  link  is  required  during  testing  and  add  the  new  configuration 
dynamically. 

With  the  test  plan  complete,  you  may  start  the  tests  via  option  1,  "Start 
testing,"  from  the  test  operations  main  menu.  A  test  summary/ status  report 
of  the  test  points  completed  in  each  test  type  category  will  appear  on  the 
screen  (see  example  in  fig.  6)  upon  selecting  option  1.  You  may  choose  to 
continue  with  the  test  plan  or  deviate  from  it  by  changing  the  order  in  which 
test  types  are  completed. 
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The  next  screen,  following  the  acceptance  of  a  test  type,  is  the  last  screen  to 
appear  before  control  is  handed  to  the  data  acquisition  module.  The  'Test 
Type  Summary /Status  Report"  summarizes  all  requirements  and  progress 
for  the  current  test  type  that  is  being  performed  (see  fig.  7).  The  report  lists 
various  information  about  the  system  and  the  current  level  of  testing.  This 
screen  also  displays  any  graphic  representations  of  the  system  under  test, 
complete  with  overlaid  test  points.  A  complete  report  of  the  test  status  for  the 
test  type  currently  engaged  is  also  displayed.  You  may  accept  thecomputer's 
recommendation  for  the  next  test  point  (based  on  the  test  plan)  or  select  an 
alternate  test  point  and  proceed  with  testing. 

Following  the  selection  of  a  test  point,  control  is  turned  over  to  the  data 
acquisition  module.  For  the  example  of  a  time  domain  test  point,  the  module 


Figure  6.  Example: 
test — test  summary/ 
status  report. 


TEST  -  Test  Summary/Status 

Report 

Test  Status  for 

"TANK” 

TIME  Domain 

Test  Type  #  Test 

Points 

%  Completed 

1.  Current  Injection 

10 

0 

2.  Free-field  Ill. 

21 

0 

3.  MIL- STD  'XYZ ' 

6 

0 

4.  MIL-STD  ' PDQ' 

18 

0 

FREQUENCY  Domain 

Test  Type  #  Test 

Points 

%  Completed 

1.  Shield  Effect. 

5 

0 

2.  CW  Ilium. 

16 

0 

3.  MIL-STD  ' ZYX ' 

4 

0 

Hit  RETURN  to  proceed  with  high-lighted  test 

(plan) 

or  use  cursor  to. select  alternate.  'ESC'  to 

exit 
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TEST  -  Test  Type  Sumiarg/Statui  Report 


SYSTEM  :  XH1 

TEST  TYPE  :  TRANSIENT  INJECTION 
HIL-STD  :  188-125 


SELECT  TEST  POINT 


11  TUAA1  < —  NEXT 

21  TI1AA2 
41  TI1AB1 
51  TUAA2 
91  TI1AC1 


UIEU  :  ROADSIDE 

LAST  TEST  POINT  :  31  TI3AS1 

STATUS  :  READY-CONT I HUE 


COMPLETED  TEST  POINTS 


61  TI1AC2 
71  TI2AC2 
81  TI3AC5 
31  TI3AS1 


Hit  RETURN  for  next  test  point  or  enter  alternate  number 

Q  TO  QUIT 


Figure  7.  Example:  test — test  type  summary/status  report 


initializes  itself  to  the  time  domain  testing  mode.  The  module  then  loads  the 
device  drivers  for  each  type  of  instrument  in  the  data  links.  A  typical  data 
link  would  consist  of  one  or  more  digitizers,  a  probe/sensor,  a  fiber-optic 
link  (FOL),  and  amplifiers  and/or  attenuators.  The  software  can  simulta¬ 
neously  acquire  data  on  several  data  links. 

The  module  would  first  initialize  all  the  instruments  in  the  data  link(s).  This 
initialization  includes  calibration-type  procedures  that  are  performed  once 
each  day,  and  configuring  the  instruments  with  initial  settings  for  each  data 
shot.  For  the  most  part,  this  initialization  is  not  of  concern  to  the  operator. 
Depending  on  the  type  of  digitizers  used,  initial  settings  include  sampling 
rate,  sweep  speed,  volts  per  division,  triggering  information,  input  imped¬ 
ance,  etc.  If  there  were  an  FOL  in  the  data  link,  the  software  would  turn  on 
the  fiber-optic  transmitters  and  put  in  the  proper  fiber-optic  attenuation,  if 
applicable. 

The  software  would  then  "arm"  the  digitizer(s);  i.e.,  it  would  ready  the 
digitizers  for  a  single  sweep.  The  digitizers  would  then  wait  in  ready  mode 
until  triggered  by  the  data  signal  or  appropriate  trigger  signal.  The  module 
would  then  activate  the  source,  if  applicable,  upon  your  command.  Having 
been  stored  in  the  digitizers,  the  data  would  then  be  retrieved  by  the 
software.  The  data  would  then  be  scaled  appropriately;  i.e.,  scaled  for 
digitizer-specific  settings  (volts  per  division,  time  per  division,  etc),  and  then 
scaled  to  "back  out"  the  effects  of  any  devices  in  the  data  link  such  as  FOL's, 
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probes,  attenuators,  amplifiers,  etc.  The  data  would  be  additionally  pro¬ 
cessed  by  any  mathematical  procedures  defined  by  the  system  and/or  test 
requirement  modules.  The  processed  data  and  any  baseline  data  or  pass /fail 
criteria  would  then  be  overlaid  on  a  graphic  display  (see  fig .  8).  Except  for  the 
few  essential  operations  you  need  to  do,  such  as  "telling"  the  software  to  arm 
for  a  single  sweep,  "fire"  the  source,  accept  or  reject  the  data,  etc,  these 
aforementioned  operations  would  all  be  performed  automatically  by  the 
software. 

One  of  the  biggest  problems  in  time  domain  data  acquisition  is  getting  a 
signal  "on  scale";  that  is,  getting  the  data  signal  amplified  or  attenuated  to 
the  proper  level  needed  by  the  digitizers.  The  signal  level  can  be  estimated, 
either  by  observing  previous  data  from  similar  types  of  measurements  or  by 
a  trial  and  error  method  where  several  attempts  are  made.  This  problem  is 
minimized  by  the  baseline  data  and  the  pass/  fail  criteria  in  that  they  specify 
expected  data  levels  for  a  "hard"  system.  The  signal  levels  are  adjusted  by 
attenuators  and  amplifiers  in  the  data  link. 

After  the  data  are  acquired  and  overlaid  against  the  baseline  data,  the 
software  may  suggest  sanity  checks  if  a  large  discrepancy  is  noted — i.e.,  the 
test  point  appears  to  "fail."  You  may  accept  the  data,  redo  the  test  point, 
and  /  or  act  on  corrective  actions  suggested  by  the  software.  The  data  are  then 
stored  and  you  may  proceed  to  the  next  test  point. 


Processed  data 


Figure  8.  Example:  captured  data — processed. 
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For  a  frequency  domain  test  point,  the  data  acquisition  process  is  the  same 
as  the  time  domain  procedure;  however,  there  are  some  significant  func¬ 
tional  differences.  The  frequency  domain  devices  (network  and  spectrum 
analyzers)  have  the  ability  to  "sit"  on  one  frequency  and  reiteratively 
measure  and  adjust  themselves  to  maximize  the  quality  of  the  data.  While 
this  process  slows  the  real-time  data  acquisition,  there  is  no  need  for  data- 
level  predictions  or  trial-and-error  data  collection,  as  is  the  case  for  time 
domain  testing.  Additionally,  since  there  is  a  time  lag  between  each  fre¬ 
quency  point,  the  raw  data  may  be  displayed  real-time. 

Another  major  difference  between  the  two  test  domains  is  the  speed  at  which 
data  are  processed.  At  a  minimum,  each  data  shot  is  processed  to  remove  the 
effects  of  the  instruments  in  the  data  link.  The  calibration  files  for  the 
instruments  are  usually  stored  as  frequency  domain  transfer  functions. 
Therefore,  removing  instrument  effects  from  frequency  domain  data  re¬ 
quires  only  simple  arithmetic,  whereas  the  same  process  for  time  domain 
data  involves  complex  and  time-consuming  transformations  and  inverse 
transformations.  It  is  obvious  that  each  test  domain  has  its  pros  and  cons, 
emphasizing  the  need  for  the  da  ta  acquisition  module  to  initialize  itself  to  the 
proper  testing  domain. 

Upon  completion  of  the  current  test  point,  control  is  returned  to  the  main 
program  shell  at  the  same  point  control  was  given  to  the  test  module,  namely 
the  'Test  Type  Summary /Status  Report."  You  can  simply  continue  with 
successive  test  points  in  the  test  plan  or  continue  to  deviate  from  the  original 
test  plan.  You  can  even  back  up  one  level  to  the  'Test  Summary /Status 
Report,"  and  start  a  different  test  type  even  though  all  test  points  in  the 
previous  test  type  were  not  completed.  In  any  case,  the  software  will 
continually  try  to  force  you  to  follow  the  original  test  plan,  simply  tracking 
and  skipping  over  test  points  that  were  completed  outside  the  test  plan 
order. 

4.  Requirements  and  Limitations 

Some  aspects  of  the  LCNS  software  require  responsibilities  to  be  established 
for  the  PM  and  test  technicians  so  the  software  can  function  coherently  in  the 
overall  LCNS  program.  It  is  envisioned  that  the  system's  PM  be  ultimately 
responsible  for  the  development  of  the  system  and  test  requirements  mod¬ 
ules  for  the  system,  although  the  PM  may  "farm  out"  this  effort  or  pass  it  on 
to  another  party  such  as  the  TMDE  PM  or  an  LCNS  PM.  It  is  also  suggested 
that  the  PM  supply  the  graphic  depictions  with  test  overlays;  however,  the 
graphics  module  contains  a  drawing  package  that  allows  you  to  create 
graphic  representations  if  you  wish.  The  PM  is  also  responsible  for  the 
maintenanceofhissystem'sLCNSdatabaseandshoulddisseminatebaseline 
and  historic  data,  in  the  proper  format,  to  the  TMDE  suites. 
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The  LCNS  TMDE  suite  operator  is  responsible  for  the  upkeep  of  the  facilities 
modules  and  the  routine  maintenance  and  calibration  of  test  instrumenta¬ 
tion.  This  operator  is  also  responsible  for  assuring  that  all  tests  have  been 
completed  correctly,  as  required  by  the  system  and  test  requirements 
modules,  and  for  delivering  the  new  data  to  the  PM  in  the  proper  format. 

Although  the  LCNS  has  many  intelligent  control  features  to  minimize  data 
collection  errors,  it  is  certainly  not  foolproof.  It  is  the  objective  of  the  LCNS 
software  to  indicate  any  obvious  discrepancies  and  provide  sanity  checks  on 
details  that  can  easily  be  overlooked.  The  operators  must  have  sufficient 
technical  background  and  training  to  function  in  the  defined  role. 

5.  Future  Implementations 

There  is  a  primary  need  for  an  administrative  group  to  oversee  the  LCNS 
program.  This  group  would  be  responsible  for  the  following  activities: 

•  developing  and  disseminating  any  changes  or  additions  to  the  LCNS  soft¬ 
ware,  modifying  the  test  requirement  modules  that  accompany  new  MIL- 
STDs,  or  modifying  existing  MIL-STD  modules, 

•  supplying  engineering  support  for  software  debugging  and  aiding  indi¬ 
vidual  TMDE  suites  in  developing  test  and  instrument  driver  modules,  and 

•  assisting  the  PM  in  developing  system  and  test  requirement  modules. 

Although  not  mentioned  above,  there  is  a  concern  for  the  security  of  LCNS 
data.  LCNS  data  can  potentially  indicate  vulnerabilities  of  military  systems, 
therefore,  precautions  must  be  taken  to  secure  these  data.  Various  warnings, 
password  protection,  and  encryption  techniques  could  be  incorporated  into 
the  LCNS  software  for  secure  operations.  These  procedures  should  be 
mandated  by  the  LCNS  administrative  group. 

As  with  all  software  packages,  there  is  a  cycle  of  test-debug-modification 
that  will  inevitably  be  applied  to  the  LCNS  software.  The  modularity  of  the 
software  lends  itself  to  a  mixed  language  composition;  therefore,  it  is 
thought  that  the  final  package  will  comprise  several  different  computer 
languages.  Each  module  will  be  written  in  the  language  that  is  most  suited 
for  the  module's  function  (e.g.,  "C"  for  graphics  and  FORTRAN  for  numeri¬ 
cal  operations  and  data  processing). 

6.  Summary 

A  comprehensive  software  concept  for  controlling  LCNS  data  acquisition 
has  been  designed  and  demonstrated.  The  modular  design  of  the  software 
has  intrinsic  characteristics  that  enable  it  to  cope  with  changes  in  instrumen¬ 
tation  technologies,  changes  in  MIL-STDs,  and  the  logistical  problems 
associated  with  an  Army-wide  LCNS  program. 
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The  development  or  modification  of  system  requirements,  MIL-STDs,  and 
instrumentation  are  incorporated  into  the  LCNS  software  through  isolated 
changes  in  the  appropriate  modules.  These  changes  eliminate  the  need  to 
develop  entirely  new  software  systems  to  accommodate  the  new  develop¬ 
ments  and  modifications. 

If  the  goal  to  have  all  Army  LCNS  TMDE  test  suites  operating  under  this 
software  is  achieved,  then  many  of  the  ambiguities  in  performing  and 
interpreting  LCNS  tests  will  be  eliminated.  With  all  test  suites  performing 
the  same  tests,  in  the  same  manner,  all  LCNS  data  will  be  either  equally  valid 
or  equally  invalid.  Even  if  one  assumes  the  worst  (all  the  LCNS  is  invalid), 
there  is  consistency,  and  corrective  actions  may  be  applied  globally  to  the 
data.  Furthermore,  there  will  no  longer  be  the  potential  for  one  test  engineer 
to  interpret  a  MIL-STD  procedure  differently  from  another  test  engineer* 

All  LCNS  data  will  be  collected  and  transferred  in  a  common  data  format, 
which  greatly  enhances  the  manageability  of  a  system's  LCNS  program. 
Since  this  common  format  applies  to  all  Army  systems,  an  Army-wide  LCNS 
database  will  provide  a  complete  and  comprehensive  evaluation  of  the 
LCNS  program  itself  as  well  as  the  LCNS  of  the  entire  Army  inventory. 
Similarly,  the  Army  will  experience  accelerated  corrective  and  maintenance 
processes  that  ensure  the  survivability  of  the  Army. 

Once  the  LCNS  software  has  been  fully  implemented,  there  is  significant 
potential  for  cost  savings.  Any  changes  or  upgrades  to  the  LCNS  software 
would  be  performed  by  one  command  and  distributed  throughout  the 
Army's  TMDE  network.  There  should  not  be  a  waste  of  funds  as  a  result  of 
duplication  of  efforts.  Any  individual  TMDE  suite  may  apply  more  re¬ 
sources  towards  advanced  technology  instrumentation  without  budgetary 
concern  for  software  designs  which  normally  accompany  a  test  suite  up¬ 
grade. 

Finally,  it  must  be  emphasized  that  the  LCNS  software  can  potentially  be 
applied  to  any  test  scenario.  Specific  modules  may  be  developed  to  satisfy 
specific  applications,  or  the  software  can  function  in  a  generic  test  role  to 
accommodate  all  types  of  testing.  The  strength  of  the  software,  however,  lies 
in  production-type  test  operations.  The  software  has  the  potential  to  meet 
changing  needs  in  instrumentation  and  test  requirements  for  many  years. 


*Some  MIL-STDs  are  defined  rather  loosely  and  permit  wide  excursions  within  defined  bounds. 


18 


Distribution 


Administrator 

Defense  Technical  Information  Center 
Attn:  DTIC-DDA  (2  copies) 

Cameron  Station,  Building  5 
Alexandria,  VA  22304-6145 

Director 

Defense  Intelligence  Agency 
Attn:  DIO/SPRD,  D.  Spohn 
Attn:  RTS-2A,  Technical  Library 
Washington,  DC  20301 

Defense  Nuclear  Agency 

Attn:  RAEE,  Electronics  Effects  Div 

Attn:  RAAE,  Atmospheric  Effects  Div, 

B.  Prasad  (2  copies) 

Attn:  RAEV,  Electromagnetic  Applications 
Div 

Attn:  TISI,  Scientific  Information  Div 
6801  Telegraph  Road 

Alexandria,  VA  22310-3398 
Deputy  Director  for  Research  and  Engineering 
(Science  and  Technology) 

Attn:  Room  3E118 
Pentagon 

Washington,  DC  20301-3080 
Director 

US  Army  Ballistics  Research  Laboratory 
Attn:  SLCBR-DD-T  (STINFO) 

Aberdeen  Proving  Ground,  MD  21005-5066 

Commander 

US  Army  Materiel  Command 
Attn:  AMCAM-CN 
5001  Eisenhower  Avenue 
Alexandria,  VA  22333-0001 

Director 

US  Army  Missile  Command  (USAMICOM) 
Attn:  AMSMI-RD-CS-R,  Documents 
Redstone  Arsenal,  AL  35898-5400 


Commander 

US  Army  Nuclear  and  Chemical  Agency 
Attn:  MONA-NU,  A.  Renner 
Attn:  MONA-NU,  R.  Pfeffer 
7500  Backlick  Road,  Building  5073 
Springfield,  VA  22150-3198 

Director 

US  Army  TMDE  Activity 
Attn:  AMXTM-S-A,  C.  Bosco 
Redstone  Arsenal,  AL  35898-5400 

Commander 

Atmospheric  Sciences  Laboratory 
Attn:  STEWS-IM-ST,  Technical  Library 
White  Sands  Missile  Range,  NM  88002-5030 

Naval  Research  Laboratory 
Attn:  4200,  Center  for  Space  Sensing 
Attn:  4600,  Condensed  Matter  and  Radiation 
Sciences 

Attn:  4700,  Plasma  Physics  Division 
Attn:  5700,  Tactical  Electronic  Warfare 
Division 

Attn:  6800,  Electronic  Science  &  Technology 
Division 

Attn:  8000,  Center  for  Space  Technology 
Attn:  4820,  Technical  Info  Div 
4555  Overlook  Avenue  SW 
Washington,  DC  20375-5000 

Naval  Surface  Warfare  Center,  Dahlgren 
Division 

Attn:  Code  E231,  Technical  Library 
Dahlgren,  VA  22448-5020 

Air  Force  Phillips  Laboratory 
Attn:  PL/WSR,  C.  Baum 
Albuquerque,  NM  87116-008 

Department  of  the  Air  Force 
Attn:  HQUSAFA/DFSELD 
USAF  Academy,  CO  80840-5701 


19 


Distribution 


Lawrence  Livermore  National  Laboratory 
Attn:  L-156,  M.  Bland 
Attn:  L-86,  Hriar  S.  Cabayan 
PO  Box  808 
Livermore,  CA  94550 

Sandia  National  Laboratories 
Attn:  Organization  3141,  Reports  Acquisition 
PO  Box  5800 
Albuquerque,  NM  87185 

National  Institute  of  Standards  and 
Technology 

Attn:  V.  Ulbrecht,  Research  Information 
Center 

Room  E01,  Building  101 
Gaithersburg,  MD  20899 

US  Army  Laboratory  Command 
Attn:  AMSLC-DL,  Dir  Corp  Labs 

USAISC 

Attn:  AMSLC-IM-VA,  Admin  Ser  Br 
Attn:  AMSLC-IM-VP,  Tech  Pub  Br 
(2  copies) 


Harry  Diamond  Laboratories 

Atm:  Laboratory  Directors 

Atm:  SLCHD-CS,  Chief  Scientist 

Atm:  SLCHD-NW,  Director 

Atm:  SLCHD-NW-E,  Deputy  Director 

Atm:  SLCHD-NW-EP,  Chief 

Atm:  SLCHD-NW-ES,  Chief 

Atm:  SLCHD-NW-HPM,  Chief 

Attn:  SLCHD-NW-P,  Chief 

Atm:  SLCHD-NW-RF,  Chief 

Atm:  SLCHD-NW-RP,  Chief 

Atm:  SLCHD-NW-RS,  Chief 

Atm:  SLCHD-NW-TN,  Chief 

Attn:  SLCHD-NW-TS,  Chief 

Attn:  SLCHD-SD-TL,  Library  (3  copies) 

Attn:  SLCHD-ST,  Director 

Attn:  SLCHD-TA,  Director 

Attn:  SLCHD-TL,  Library  (Woodbridge) 

Atm:  SLCHD-NW-ES,  N.  Tesny  (15  copies) 

Attn:  SLCHD-NW-ES,  V.  Ellis  (15  copies) 


20 


